docs: surface real-provider E2E testing - #123

The pushed Phase 1 harness failed its first real CI run against
firstsun-dev/git-files-sync (run 31665711682). Root causes, all found by
reading the actual job logs:

- github/gitlab legs: the vitest step's generated GitVerifier shells out to
  git, but GIT_ASKPASS/GIT_TERMINAL_PROMPT only ever existed inside the
  provision/seed/cleanup steps' own processes -- the vitest step is a
  separate process that only sources e2e.env, which never carried them.
  `git fetch` prompted for a username and failed. Now persisted (as a path,
  not a secret -- the token itself stays only in the mode-700 askpass file
  on disk) in e2e.env's write_env_file/load_env_file.

- gitea leg: provisioning timed out waiting on `127.0.0.1:<host-port>` --
  this runner fleet is itself a sibling container of the Docker daemon, so a
  published host port is only reachable from the Docker host's own network
  namespace, not from a sibling container's. Switched to the gitea
  container's own bridge IP (reachable from any container on the same
  default Docker network, including a sibling runner), dropping the -p
  mapping entirely.

- gitea leg's cleanup step then also failed: cmd_cleanup called
  setup_askpass unconditionally before branching on provider, but gitea's
  cleanup is pure `docker rm` and needs no git credentials -- and since
  provision had already failed before provisioning a token, there was
  nothing for setup_askpass to require. Gitea's branch now runs first and
  skips setup_askpass entirely.

Verified with another real end-to-end run against a live local Gitea
sandbox (npm run test:e2e -- --provider gitea): 14/14 passed, using the
container's bridge IP this time. Full gate still green: eslint 0 errors,
build clean, vitest 527/527.

Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>

The github/gitlab-fix push (1393956) triggered a second real CI run: both
github and gitlab legs passed this time, confirming the GIT_ASKPASS/
GIT_TERMINAL_PROMPT propagation fix. The gitea leg hung for 10+ minutes on
"Provision isolated branch/container" -- well past the 60s ready_ms budget
-- and had to be cancelled manually.

Root cause: none of the curl calls in provision_gitea_container had a
--max-time. A curl against an unreachable/blackholed address (e.g. an empty
container_ip if `docker inspect` raced the container's network attachment)
can hang far longer than the health-check loop's own timeout budget,
instead of failing fast into the next retry -- the loop's `waited -ge
ready_ms` check never gets a chance to fire if a single curl call itself
never returns.

Fixes: retry docker inspect up to 10x/1s if container_ip comes back empty
before ever starting the health loop (fail fast with a clear error if it
never does); --max-time on every curl call in this function (5s for the
per-poll healthz check, 15s for the one-shot repo/token/user setup calls
and the gitlab project-lookup call in normalize_env).

Verified locally again (timed): full provision -> seed -> vitest -> cleanup
in 13.6s, no hangs. Full gate still green.

Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>

The gitea leg still needs more investigation against this specific
self-hosted runner fleet's Docker topology (bridge-IP reachability, health-
check timing already needed two rounds of fixes) -- not something safe to
keep iterating on inside the shared provider-e2e matrix while github/gitlab
are otherwise green. Gate it off via the existing per-provider "Determine
whether this leg should run" step rather than removing it from the matrix,
so job structure/naming stays stable for whoever re-enables it.

Suite and harness code (e2e/suites/gitea.e2e.test.ts, scripts/e2e-
harness.sh's gitea path) is untouched -- verified locally again just now
(`npm run test:e2e -- --provider gitea`, 14/14 passed, 13.6s) -- only CI
execution is paused pending runner-environment follow-up. Re-enable by
deleting the added `if` block once confirmed.

Note: gitea is normally what covers fork PRs without needing real
credentials -- while disabled, fork PRs get zero E2E coverage. Acceptable
short-term given this branch has no open fork PRs yet.

Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>